【コストに注意】CloudWatch Logs Insightsのスキャン容量はCloudWatch Logsに取り込まれる圧縮前のデータ量です

公式ドキュメントに明確な記載がなかったため書きました。

#AWS

#CloudWatch Logs

#CloudWatch Logs Insights

おつまみ

2024.08.19

こんにちは！AWS事業本部のおつまみです。

みなさん、 CloudWatch Logs Insights普段活用していますか？私は活用しています。

CloudWatch Logs Insightsは、CloudWatch Logs 内にあるログデータを効率的に分析し、有用な洞察を得るための強力なツールです。

大変便利な機能ですが、コスト面で注意すべきポイントがあります。
そこで今回は実際に起きてしまった具体的な事象を交えて、CloudWatch Logs Insightsを使用する際に知っておくべき重要な点についてご紹介をします。

いきなり結論

CloudWatch Logs Insightsは スキャンされる容量 あたりのコストがかかる。
スキャンされるデータ容量はCloudWatch Logsに保管される 圧縮前 のデータ容量である。
CloudWatch Logs に保存されるデータは元のデータの 15% 程度 まで自動圧縮されるようだが、データ形式によっては さらに圧縮される 可能性がある。
CloudWatch Logs Insightsでクエリを投げる場合には、スキャンする際のデータ量が削減されるようクエリを最適化しよう。

今回起きてしまった事象について

事象

今回とある環境でCloudWatch Logsのコストが急激に増加していました。（調査時点で約4.7TBのログを取り込んでおり、$3,000強のコストが発生していました。）

原因調査①

まずどのログが原因かを調査するため、Cloudwatch Logsへのログ取り込み量メトリクスincomingBiytesを確認しました。すると、Auroraのpostgresqlログの容量が肥大化していることが判明しました。

そして、postgresqlログをCloudWatch Logsで確認したところ主に監査ログやスロークエリログなどが出力されていることが確認できました。（AUDITで始まるログが監査ログ、durationで始まるログがスロークエリログです。）

原因調査②

ログ容量削減するために、postgresqlログに対して監査ログやスロークエリログがどのくらいの割合を占めているか確認することにしました。

そこでCloudWatch Logs Insights でスロークエリログのみの容量を把握しようと、8/1~8/13の期間で以下のクエリを実行しました。

fields @timestamp, @message
| filter @message like /duration:/
| stats sum(strlen(@message)) as total_size

すると、CloudWatch Logs のデータ保管容量は約200GBだったのに対し、4.2TBのデータがスキャンされてしまいました。

CloudWatch Logs のデータ保管容量（約200GB）

CloudWatch Logs Insights でスキャンしたデータ容量（4.2TB）

その結果、たった1回のクエリで約＄30のコストが発生してしまいました。。。

AWS_アカウント詳細.png

判明したこと

今回起きてしまった事象によって、以下の2点が判明しました。

CloudWatch Logs Insightsでスキャンされるデータ容量はCloudWatch Logsに保管される 圧縮前 のデータ容量である。
CloudWatch Logs に保存されるデータは元のデータの 15% 程度 まで自動圧縮されるようだが、データ形式によっては さらに圧縮される 可能性がある。

内容を掘り下げたいと思います。

CloudWatch Logs Insightsのコストについて

CloudWatch Logs Insightsのコストはスキャンされたデータ容量に対して、コストが発生します。

分析 (Logs Insights のクエリ) スキャンしたデータ 1 GB あたり USD 0.0076（東京リージョン）

引用：料金 - Amazon CloudWatch | AWS

ここで注目すべき重要なポイントがあります。

今回の事象で判明したようにCloudWatch Logs Insightsでスキャンされるデータ量は、CloudWatch Logsに取り込まれる　圧縮前　の容量であるということです。つまり、実際にCloudWatch Logsに保存されているデータ量よりも多くのデータがスキャンの対象となり、それに応じてコストが発生します。

CloudWatch Logsのデータ圧縮は必ずしも15％にはならないこと

CloudWatch Logs に取り込まれたログは AWS によって自動で元のデータの 15% 程度まで圧縮されるといわれています。
AWS Pricing Calculatorで、4.2TBのデータ量を取り込んだ時のコストを計算してみると、0.15 ストレージ圧縮係数が存在しています。

このことから、ログボリュームはアーカイブ後、取り込まれたログボリュームの15%になると推測されます。

しかし、今回CloudWatch Logs の保管されていたデータ容量は約200GBでした。15%の圧縮率を想定すると、4.2TB × 0.15 = 0.63TB (630GB)になるはずです。

いったいなぜでしょうか？？
この差異の理由は、CloudWatch Logs の 圧縮形式と元データの特性 によるものと考えられます。

CloudWatch Logs の圧縮形式はgzip レベル 6 圧縮であることが公式ドキュメントに記載されています。

CloudWatch Logs から Amazon Data Firehose に送信されるデータは、すでに gzip レベル 6 圧縮で圧縮されているため、Firehose 配信ストリーム内で圧縮を使用する必要はありません。

引用：ロググループレベルのサブスクリプションフィルター

gzipレベル6の圧縮率は通常15%程度ですが、テキストデータで同じような内容が繰り返し出力される場合、圧縮率はさらに高まる傾向があります。

gzip圧縮の圧縮率は、元のデータの性質によって大きく異なります。一般的に、テキストデータや繰り返しパターンが多いデータは、高い圧縮率が得られる傾向にあります。

引用：圧縮コマンドのgzipとは？意味をわかりやすく簡単に解説 – xexeq.jp

今回のpostgresqlログは、監査ログやスロークエリログが中心で、 同じ文字列が頻繁に出現していたため 、元のログデータ容量よりもかなり圧縮されたと考えられます。

結論として、CloudWatch Logs に保存されるデータは元のデータの15%程度まで自動圧縮されるが、データの特性によってはさらに高い圧縮率が達成される可能性があることが判明しました。

CloudWatch Logs Insightsのコスト最適化のためのヒント

今回CloudWatch Logs Insightsのコストが想定より発生してしまいましたが、どのようにすればよかったのでしょう？
以下の方法でコスト最適化を図ることができます。

クエリ内容を見直す

まず、クエリの内容を見直すことが重要です。
クエリ対象範囲の指定、実行頻度の見直しなどが効果的です。

詳細はこちらのブログをご参考ください。

~~なおクエリの内容によるスキャン量は削減できないので、ご注意ください。~~
詳細はこちらのブログをご参考ください。

CloudWatch Logsの容量を抑える

次に、スキャン対象となるCloudWatch Logsの容量を抑えることも重要です。

ログの保持期間を適切に設定し、不要なログを自動的に削除することで、CloudWatch Logs自体のコストを削減できます。さらに、ログフィルタを使用して重要なログのみを保存したりすることも有効です。

詳細はこちらのブログをご参考ください。

最後に

今回は、CloudWatch Logs Insightsのコストについてご紹介しました！

CloudWatch Logs Insightsヘビーユーザーの皆さんも想定外のコストが発生していないか確認してみてください！

最後までお読みいただきありがとうございました！

以上、おつまみ（＠AWS11077）でした！

【コストに注意】CloudWatch Logs Insightsのスキャン容量はCloudWatch Logsに取り込まれる圧縮前のデータ量です

いきなり結論

今回起きてしまった事象について

事象

原因調査①

原因調査②

判明したこと

CloudWatch Logs Insightsのコストについて

CloudWatch Logsのデータ圧縮は必ずしも15％にはならないこと

CloudWatch Logs Insightsのコスト最適化のためのヒント

クエリ内容を見直す

CloudWatch Logsの容量を抑える

最後に

参考

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社